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1.0  INTRODUCTION 


Prior  to  1990,  modeling  &  simulation  (M&S)  efforts  within  the  Department  of  Defense 
(DoD)  was  fragmented  and  lacked  coordination  across  all  the  Services.  As  a  result. 
Congress  directed  DoD  to  establish  a  joint  program  office  for  simulation  to  coordinate 
policy,  establish  interoperability  standards  and  protocols,  promote  simulation  within  the 
military,  establish  guidelines  and  objectives  for  coordination  of  simulation,  wargaming, 
and  training.  This  joint  program  office  was  established  under  the  Office  of  the  Secretary 
of  Defense  (OSD),  and  designated  the  Defense  Modeling  and  Simulation  Organization 
(DMSO). 

The  new  direction  has  brou^t  about  significant  advances  in  M&S  in  four  areas: 

•  Architectures,  standards,  and  protocols 

•  Representation  of  the  environment,  systems,  and  human  behavior 

•  Fielding  of  M&S  and  associated  infirastructure 

•  Outreach  activities 

This  new  direction  in  M&S  forced  a  new  idea  originally  called  Advanced  Distributed 
Simulation  (ADS).  This  proved  to  be  a  major  advance  in  real-time  simulation  ability,  by 
being  able  to  create  large  virtual  worlds  in  which  many  subjects  could  interact.  By 
electronically  linking  individual  simulations,  the  creation  of  a  virtual  world 
revolutionizes  planning,  training,  testing,  analysis,  and  acquisition. 

This  document  will  discuss  the  DoD  vision  for  M&S  established  in  the  early  1990’s,  and 
will  identify  the  trends  in  ADS  interoperability  and  architecture. 


2.0  DoD  VISION  FOR  M&S 

As  stated  in  the  DoD  M&S  Master  Plan  (ref.  1)  the  Vision  encompasses  models  and 
simulations  ranging  from  high-fidelity  engineering  models  to  highly  aggregated, 
campaign-level  simulations  involving  joint  forces.  It  includes  all  types  of  models  and 
simulations  containing  a  full  range  of  M&S  interaction  between  scope  of  the  simulation, 
sponsoring  component  objectives  and  functional  area  requirements.  Figure  1  illustrates 
the  range  of  M&S  contained  by  the  DoD  Vision.  It  notes  there  are  many  other 
perspectives  of  M&S  including  the  level  of  resolution,  degree  of  human  participation, 
degree  of  physical  realism,  time-management  method,  time-step  resolution,  degree  of 
distribution,  and  computational  complexity. 

The  advanced  M&S  concepts  may  integrate  a  mix  of  constructive  computer  simulations, 
system  simulators,  as  well  as  real  system  hardware.  These  simulation  components 
(entities)  may  be  distributed  geographically  and  connected  through  a  high-speed  network 
and  will  allow  users  to  train  and  analyze  operational,  or  strategic  levels  of  war  through 
the  use  of  synthetic  environments  representing  potential  opponents  in  any  region  of  the 
world,  with  realistic  interaction.  Personnel  may  use  the  same  synthetic  environments  for 
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research,  development,  and  test  and  evaluation  activities  as  well  as  to  support  the 
acquisition  decision  making  process.  M&S  will  increasingly  be  used  to 
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Figure  1.  Range  of  M&S  contained  by  the  DoD  M&S  Vision  (ref.  1) 

reduce  cost,  improve  efficiency  and  effectiveness  in  engineering  development  and  system 
design,  manufacturing,  and  logistical  support  functions.  As  discussed  in  reference  1, 
there  are  six  activities  required  for  transforming  the  Vision  into  reality  as  shown  below  in 
figure  2. 


Figure  2.  DoD  M&S  Activity  Model  (ref  1) 
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a.  Provide  Management,  Policy  &  Guidance.  Each  DoD  Component  publishes 
appropriate  directives,  establishes  organizations  to  support  its  M&S  activities,  and 
develops  plans  and  budgets  to  satisfy  the  M&S  needs  of  its  Active  and  Reserve 
components  as  well  as  those  of  the  United  Combatant  Commands  and  other  DoD 
Components.  The  Under  Secretary  of  Defense  for  Acquisition  and  Technology 
(USD(A&T))  may  assign  responsibility  for  development  and  maintenance  of  a 
specific  common  or  general-use  M&S  capability  to  a  DoD  Component  by  formally 
designating  the  Component  as  an  Executive  Agent.  The  DoD  Components  may  also 
further  their  M&S  goals  by  organizing  partnerships  within  their  own  organizations  or 
with  other  DoD  Components  to  address  common  interests.  Each  Component  must 
make  prudent  investments  to  achieve  DoD’s  M&S  objectives. 

b.  Assess  M&S  Requirements.  The  needs  of  all  DoD  users  must  be  identified  and  an 
assessment  must  be  made  to  determine  the  potential  and  cost-effectiveness  of  M&S  to 
satisfy  the  needs.  The  resulting  M&S  requirements  must  be  prioritized  for  use  in 
program  planning,  budgeting,  and  execution. 

c.  Develop  Technology.  It  is  necessary  to  continually  monitor  ongoing  industry  and 
government  technology  developments  and  assess  the  risk  and  cost-benefit  of  the 
technologies  to  support  the  requirements  of  the  DoD  Components  for  M&S.  The 
technology  shortfalls  must  be  identified  and  priorities  must  be  developed  for  DoD 
investments  to  exploit  technology  advances  in  a  timely  manner,  accelerate 
technological  development,  fill  technology  gaps,  and  rapidly  insert  the  acquired 
technology  into  M&S  applications.  The  Director  of  Defense  Research  and 
Engineering’s  (DDR&E)  Technology  Area  Plan  and  M&S  Technology  Area 
Review/Assessment  are  central  facets  of  this  activity. 

d.  Build  M&S  Capability.  A  technical  firamework  must  be  developed  to  ensure 
appropriate  interoperability  across  different  simulations;  reuse  of  simulation 
components;  insertion  of  new  technologies;  and  flexibility  to  respond  to  changing 
requirements.  Then  the  DoD  Components  must  employ  the  necessary  technology  to 
build  the  M&S  representations  (e.g.,  entities,  applications  and  systems)  and  ensure 
they  are  populated  with  certified  data.  These  representations  must  then  be  verified, 
validated,  and  integrated  to  provide  a  useful  M&S  capability. 

e.  Field  the  Capability.  The  DoD  Components  must  plan  the  fielding  of  required  M&S 
applications  and  systems.  The  required  staffing,  communications,  data,  and 
management  infi'astructure  must  be  provided;  the  M&S  software  and/or  systems  must 
be  delivered  to  the  users;  and  the  users  must  be  properly  trained  in  their  use,  including 
how  to  make  accreditation  and  certification  decisions.  Users  will  then  employ  the 
M&S  capabilities  to  improve  readiness,  support  modernization,  and  support  force 
stmcture  and  sustainment  decisions.  Configuration  Management  policies  will  ensure 
consistent,  compatible  M&S  usage  across  the  DoD  Components. 

f.  Share  the  Benefits  of  M&S.  The  optimal  use  of  M&S  across  DoD  will  not  occur 
unless  the  positive  (and  negative)  impacts  and  cost-effectiveness  of  M&S  are 
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documented  and  communicated.  The  DoD  Components  must  educate  potential  user 
communities  on  the  existing  and  expected  benefits  of  M&S  emplo5nnent  so  that  they 
make  informed  investment  decisions.  This  education  may  include  a  wide  variety  of 
means,  such  as  on-line  information  systems,  seminars,  live  demonstrations,  formal 
courses  of  instruction,  etc.  Where  authorized  and  cost-effective,  DoD  must 
aggressively  pursue  the  exchange  of  M&S-related  requirements,  concerns,  ideas,  and 
technology  among  the  DoD  Components,  other  Government  Agencies,  academia, 
industry,  and  allied  nations. 


3.0  DISTRIBUTED  INTERACTIVE  SIMULATION 

In  1983  a  program  to  establish  a  network  of  single  trainer  simulations  into  team  trainers 
was  created.  This  program  called  Simulation  Networking  (SIMNET)  was  sponsored  by 
Advanced  Research  Projects  Agency  (ARP A)  and  launched  a  new  technology  known  as 
ADS.  SIMNET  was  successful  in  that  it  networked  over  300  simulators  with  the 
technology  that  was  to  develop  into  Distributed  Interactive  Simulation  (DIS). 

DIS  is  based  on  a  standard  set  of  messages  and  rules  called  Protocol  Data  Units  (PDU) 
which  are  used  for  sending  and  receiving  information  across  a  computer  network.  The 
most  common  message  is  the  Entity  State  PDU  which  represents  all  of  the  state 
information  about  a  simulated  entity  (i.e.,  tank,  aircraft,  rocket,  human,  etc.)  that  another 
simulator  needs  to  know.  An  Entity  State  PDU  contains  data  about  an  entity’s  position 
and  velocity.  By  using  position,  velocity,  acceleration,  and  rotational  velocity  data,  a 
receiver  is  able  to  extrapolate,  or  dead  reckon,  a  vehicles’  position  before  the  arrival  of 
the  next  PDU,  thereby  reducing  consumption  of  network  bandwidth.  Dead  reckon  means 
a  simulator  is  able  to  recognize  data  witliin  a  PDU  has  not  changed,  firom  the  previous, 
and  therefore  the  Entity  State  is  unchanged.  Dead  reckoning  is  a  technique  that  reduces 
the  frequency  at  which  information  must  be  transmitted  via  the  underlying  network, 
therefore  DIS  is  able  to  significantly  limit  the  amount  of  data  an  average  simulator 
transmits.  Dead  reckoning  permits  very  large  DIS  simulations  to  take  place.  Figure  3 
illustrates  the  ADS  and  DIS  architectures. 

Basically  in  the  ADS  architecture,  a  centralized  server  performs  the  time-step  tasks  or 
change  in  data  between  all  simulators  and  calculates  the  change  in  state  information  then 
sends  it  back  out  to  each  simulator.  In  DIS,  there  is  no  central  server.  DIS  is  a  peer-to- 
peer  architecture,  in  which  all  data  is  transmitted  to  all  simulators  where  it  can  be  rejected 
or  accepted  depending  on  what  data  the  simulator  needs.  Eliminating  a  central  server 
dramatically  reduces  time  lag,  called  latency.  This  becomes  very  important  when 
networking  simulations  and  there  is  a  requirement  to  represent  realism  or  real-time, 
especially  for  training. 

In  1994,  reports  on  Advanced  Distributed  Simulation  and  Readiness  have  recommended 
that  architectural  efforts  to  combine  live,  virtual,  and  constructive  simulation  be. 
broadened.  In  addition,  other  studies  indicated  the  need  for  architectural  activities  to 
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promote  the  interoperability  and  reuse  of  models  and  simulations  to  support  other 
functional  areas  such  as  acquisition  (ref.  1). 


Simulations  can  be  live,  virtual,  or  constructive  data  sources 
Simulation  1  Simulation  2  Simulation  3  Simulation  4 
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ADS  uses  a  central  server 
to  make  the  decisions 
about  what  information 
goes  where 


DIS  is  peer-to-peer 
architecture  which 
uses  PDUs,  so  each 
simulator  decides 
what  information  it 
needs 


Figure  3.  ADS  and  DIS  Architectures 

It  was  noted  that  interoperability  and  reuse  were  limited  because  DoD  lacked  a  common 
technical  framework  for  simulation  architecture.  As  a  result,  developed  a  consensus  that 
DoD  must  establish  such  a  framework  to  facilitate  the  interoperability  of  all  types  of 
models  and  simulations  among  themselves  and  with  C4I  Systems,  as  well  as  to  facilitate 
the  reuse  of  M&S  components.  This  soon  turned  into  a  program  established  by  ARPA  to 
develop  DIS  standards  (IEEE  Standard  1278). 


3.1  DIS  AREAS  OF  STANDARDIZATION 

The  DIS  standards  establish  a  common  data  exchange  environment,  also  known  as  a 
common  messaging  environment,  using  PDUs,  that  supports  the  interoperability  of 
heterogeneous,  geographically  distributed  live  (operational  platforms  and  test  and 
evaluation  systems),  virtual  (human-in-the-loop  simulators)  and  constructive  entities 
(wargames  and  other  automated  simulations).  As  discussed  in  reference  2,  the  following 
DIS  areas  of  standardization  include  interface  definition,  communication,  security. 
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management,  representation  of  the  environment,  field  instrumentation,  and  performance 
measurement. 


3.1.1  Interface  Definition 

The  definitions  of  how  information  must  flow  between  simulations  in  order  to  be 
interoperable  include: 

•  Identification  of  data  items 

•  A  common  representation  of  these  data  items 

•  The  assembly  of  these  data  items  into  formatted  messages,  called  PDUs 

•  The  circumstances  (including  time)  under  which  these  PDUs  are  transmitted 

•  The  processing  that  must  be  done  on  receipt  of  PDUs 

•  Key  algorithms  (e.g.  dead  reckoning)  that  must  be  implemented  by  all 
participants 

These  definitions  have  been  documented  in  the  IEEE  Standard  1278.  This  initial  version 
defines  the  PDUs  needed  to  support  the  appearance  and  movement  of  entities,  firing  of 
weapons,  detonation  of  ordnance,  collision  detection,  and  logistical  resupply  of  units. 

Subsequent  versions  of  this  docmnent  are  available  (DIS  2.X  series)  to  support  current 
developments.  These  new  versions  correct  shortcomings  and  support  new  capabilities: 

•  Simulated  voice  radio  and  tactical  data  links 

•  Simulation  management 

•  Emission  representation  in  support  of  electronic  warfare 

•  Terrain  description 

•  Environmental  effects 


3.1.2  Communication  Architecture 

DIS  PDUs  are  independent  of  network  media  and  network  protocols  being  used  to 
transmit  them.  PDUs  define  the  information  that  flows  between  simulations;  and 
communications  architecture  standards  ensure  that  the  underlying  media,  types  of  service, 
and  protocols  are  common  and  meet  key  performance  requirements.  The  areas  associated 
with  Communication  standards  are: 

•  Definition  of  addressing  (e.g.  point-to-point,  one-to-many)  capabilities 

•  Definition  of  reliability  (e.g.  error  free,  best  effort)  requirements 

•  Choice  of  communication  profile  for  flie  network  and  transport  layers  (as 
defined  by  the  International  Standards  Organization/Open  System 
Interconnection  (ISO/OSI)  technical  reference  model) 
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•  Guidance  in  determining  bandwidth  requirements  based  on  estimated  traffic 
for  exercises  of  different  sizes 

•  Definition  of  key  constraints  (e.g.  maximum  PDU  size) 

•  Definition  of  key  performance  capabilities  (e.g.  latency) 

Unlike  the  definition  of  PDUs,  which  can  be  arbitrarily  defined  to  suit  specific  DIS 
needs,  commimications  standards  are  heavily  impacted  by  what  the  communications 
industry  offers  or  is  expected  to  offer.  Many  fundamental  communications  needs  of  DIS 
(e.g.  multicast  addressing)  are  not  normal  of  traditional  communications  developments, 
which  are  based  on  the  telephone  model  of  point-to-point  connection.  This  has  made  the 
selection  of  available  services  difficult  and  has  forced  some  compromises  in  DIS 
operations. 


3.1.3  Security 

Most  DIS-based  applications  will  require  protection  of  the  information  flowing  between 
simulations.  The  applications,  which  require  protection,  will  range  from  individual 
companies  wishing  to  keep  proprietary  data  away  fi'om  competitors  to  rehearsal  of 
planned  military  operations,  the  most  sensitive  application  foreseen.  DIS  standards 
development  in  the  area  of  security  consists  of: 

•  Establishment  of  a  DIS  security  policy 

•  Publication  of  a  DIS  security  guidance  document 

•  Publication  of  security  accreditation  guidelines 

•  Establishment  of  security  services  performance  requirements 

It  should  be  noted  that  none  of  the  efforts  mentioned  above  would  in  any  way  determine 
what  data  needs  protection  or  how  well  the  data  needs  to  be  protected.  These  issues  are 
the  responsibility  of  the  authority  in  charge  of  each  DIS  simulation  application  and  will 
vary  fi’om  application  to  application.  Instead,  these  efforts  are  intended  to  assist 
accreditors,  engineers,  and  managers  in  determining  what  protection  measures  are 
available  and  how  they  may  be  most  effectively  used.  These  efforts  will  also  clarify  the 
needs  of  DIS  data  protection  mechanisms  to  help  the  developers  of  such  mechanisms 
(e.g.  encr5q)tion/decryption  devices,  secure  operating  systems,  and  key  distribution 
methods).  Another  purpose  a  standardized.accreditation  process  for  DIS-based 
applications  that  is  widely  tmderstood  and  easily  txsed. 


3.1.4  Management 

The  planning,  setup,  execution,  and  monitoring  of  a  large,  multi-site  exercise  is  a 
complex  process  that  may  ultimately  prove  to  be  a  greater  challenge  than  managing  the 
network  traffic  itself.  Significant  amounts  of  person-to-person  communication,  Via  video 
conferencing  and  other  techniques,  will  be  required  in  advance  of  an  exercise.  This  will 
insure  that  the  exercise  objectives  are  understood  and  agreed  to  by  all  parties  involved. 
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and  that  the  required  resources,  in  terms  of  simulations,  persormel,  and  commxmications 
bandwidth,  are  available  at  the  appropriate  times. 

Configuration  management  will  play  an  important  role,  particularly  where  many 
heterogeneous  simulations  are  involved.  Each  simulation  has  its  own  set  of  adjustable 
parameters,  each  of  which  must  be  recorded  if  there  is  to  be  any  chance  of  replicating  the 
exercise.  Where  interfaces  to  wargames  are  included,  they  can  easily  represent  thousands 
of  parameters  to  be  recorded. 

Other  areas  in  DIS  management  standardization  include  exercise  management,  network 
management,  and  security  management. 


3.1.5  Environment 

The  synthetic  environments  simulated  in  DIS  need  to  present  a  full-bodied,  integrated 
representation  of  land,  air,  and  sea.  A  full-bodied,  integrated  representation  includes 
other  windows  of  the  electromagnetic  spectrum  such  as  infrared  and  ultraviolet.  Two 
considerations  affect  this  issue:  fidelity  of  environmental  representation  (for  validation  of 
the  simulation  exercise  consistent  with  the  exercise  purpose),  and  correlation  of 
representations  fi'om  system-to-system  to  ensure  the  fair  fight.  The  concept  of  a  fair  fight 
also  includes: 

•  Adequate  inclusion  of  entity  capability  to  support  individual  actions  (e.g. 
controls  and  displays,  subsystems,  modes  of  operation,  physical  limitations) 

•  Accurate  representation  of  actions  by  all  affected  participants 

DIS  efforts  for  achieving  commonality  of  environmental  representation  among 
heterogeneous  simulators,  simulations,  and  range  systems  are  focused  on  an 
infi'astructure  to: 

•  Identify  common  sources  for  environmental  data 

•  Create  standards  for  the  representation  of  that  data 

•  Create  repository  databases  for  the  collection  and  storage  of  the  common  data 

•  Distribute  that  data  to  local  systems  in  an  exercise 

•  Aid  DIS  users  in  identifying  exercise  requirements  and  then  decomposing 
them  into  participant  capabilities  and  fidelity  requirements 

•  Catalog  DIS  qualified  simulation  assets  firom  which  DIS  users  can  select  an 
appropriate  subset  to  meet  exercise  goals,  including  exercise  validation 


3.1.6  Field  Instrumentation 

Instrumented  platforms  have  unique  requirements  and  historically  have  not  been 
addressed  by  DIS  standards.  To  address  these  issues  the  DIS  community  established  a 
separate  effort  to  develop  standards  that  will  allow  instrumented  platforms  to  interact 
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with  virtual  and  constructive  simulation  components  in  a  meaningful  way.  Some  of  the 
areas  addressed  include; 

•  More  compact  representation  of  data  necessitated  by  the  lower  bandwidth  of 
Radio  Frequency  (RF)  communications  used  by  the  instrumented  ranges 

•  The  special  needs  of  mobile  instrumented  platforms 

•  The  fusion  of  simulated  information  with  that  provided  by  the  sensors  of  the 
instrumented  platforms 

•  Intelligent  translation  of  information  flowing  from  the  instrumented  range  to 
the  virtual  world 

•  The  special  safety  considerations  of  live  range  interactions 

•  Interfaces  which  allow  exchange  of  tactical  data  link  information  between 
live,  virtual  and  constructive  simulations 

•  Special  protocols  to  handle  live  range  activities 


3.1.7  Performance  Measurement 

In  order  for  a  DIS-based  application  to  have  value  that  can  be  stated  objectively,  a  great 
deal  of  effort  must  be  put  into  defining,  recording,  and  analyzing  data  that  represents  the 
behavior  of  the  participants.  Such  measures  of  performance  are  essential  to  the 
Verification,  Validation,  and  Accreditation  (W&A)  needed  to  determine  whether  a 
plaimed  DIS-based  application  is  appropriate  to  its  intended  purpose.  Eventually  such 
performance  measurement  will  also  be  the  basis  of  efforts  to  determine  the  effectiveness 
of  behaviors  seen  in  DIS-based  applications. 

Standards  development  efforts  in  the  area  of  performance  measurement  center  on: 

•  Establishing  a  standard  set  of  performance  measures 

•  Developing  mechanisms  to  gather  appropriate  data 

•  Identifying  and  extracting  meaningful  parameters  from  that  data 

•  Presenting  such  parameters  in  a  marmer  that  is  easy  to  imderstand  and  absorb 

•  Collecting  data  from  remote  sites  at  a  central  location 


4.0  HIGH  LEVEL  ARCHITECTURE 

High  Level  Architecture  (HLA)  is  the  next  generation  of  modeling  and  simulation 
software  that  will  support  a  wider  range  of  applications  with  more  functionality.  As 
previously  mentioned,  DoD  has  directed  an  effort  to  establish  a  common  technical 
framework  to  facilitate  both  the  interoperability  between  the  wide  spectrum  of  modeling 
and  simulation  applications  and  the  reuse  of  the  modeling  and  simulation  components. 
This  common  technical  framework,  HLA,  is  shown  in  figure  4  and  is  considered  the 
highest  priority  effort  within  the  DoD  modeling  and  simulation  community. 


9 


4.1  GENERAL  PRINCIPLES 


HLA  uses  a  set  of  rules  to  govern  how  simulations  interoperate  with  each  other.  These 
simulations  are  referred  as  federates,  which  communicate  by  a  data  distribution 
mechanism  called  the  Runtime  Infrastructure  (RTI)  and  uses  an  Object  Model  Template 
(OMT)  which  describes  the  format  of  the  data.  This  is  analogous  to  the  PDU  and  Entity 
State  formats  used  in  DIS.  However,  HLA  does  not  specify  what  constitutes  an  object 
(objects  are  the  physical  things  that  are  going  to  be  simulated,  such  as  tanks  and 
missiles),  nor  the  rules  of  how  objects  interact.  This  is  the  key  difference  between  DIS 
and  HLA. 


Live  Participants 


Runtime  Infrastructure  (RTI) 


Federation  Management  Declaration  Management 

Object  Management  Ownership  Management 

Time  Management  Data  Distribution  Management 

Figure  4.  High  Level  Architecture  (HLA) 

In  DIS  it  would  not  be  possible  to  interact  applications  of  high-fidelity  engineering 
models  which  run  much  slower  than  real  time  and  lower-fidelity  models  which  niay  run 
at  real-time  or  faster  with  very  high  accuracy.  The  HLA  RTI  allows  different  types  of 
systems  of  different  levels  of  fidelity  and  scope  to  interact. 
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However,  this  level  of  flexibility  in  HLA  causes  an  inherent  weakness  —  unless  all  the 
HLA  simulators  in  an  exercise  agree  on  a  single  Federate  Object  Model  (FOM)  they  will 
not  be  able  to  interoperate  even  though  they  are  HLA  compliant.  The  FOM  describes  the 
objects  and  interactions  involved  in  the  federation  execution  (ref  3). 

Unlike  DIS  where  all  simulations  receive  every  piece  of  data  broadcast,  HLA  provides 
the  federates  a  more  flexible  simulation  framework  with  the  ability  to  specify: 

•  What  information  they  will  be  producing 

•  What  information  they  would  like  to  receive 

•  The  data’s  transportation  service,  e.g.  reliable,  best  effort 

•  Whether  or  not  the  federation’s  timing  mechanism  is  synchronous  or 
asynchronous 

These  points  make  it  possible  to  have  more  simulations  on  a  network  at  one  time  because 
the  amount  of  data  being  sent  is  reduced.  The  simulation  software  is  also  simplified 
because  it  does  not  need  to  process  extraneous  information. 


4.2  RULES/RATIONAL 

The  overall  objective  of  a  common  technical  framework,  is  to  support  interoperability 
and  reuse.  Therefore  it  is  essential  to  establish  certain  rules  by  which  the  HLA  must 
comply.  There  are  a  total  of  ten  HLA  rules;  five  for  federations  and  five  for  federates 
(ref  4). 


4.2.1  Federation  Rules 

A  federation  is  a  named  set  of  interacting  federates,  a  common  federation  object  model 
and  supporting  Runtime  Infrastructure,  that  are  used  as  a  whole  to  achieve  a  specific 
objective.  Below  are  the  five  rules  and  rational  that  apply  to  HLA  federations. 

1.  Federations  shall  have  an  HLA  Federation  Object  Model  (FOM),  documented  in 
accordance  with  the  HLA  Object  Model  Template  (OMT).  The  FOM  is  the  fundamental 
element  in  defining  a  federation.  It  shall  document  the  agreement  among  federates  within 
the  federation  data  to  be  exchanged  at  runtime  and  the  conditions  of  the  data  exchange. 
The  requirement  that  FOMs  be  documented  in  accordance  the  HLA  OMT  is  to  support 
reuse  of  a  federation  by  new  users. 

2.  In  a  federation,  all  simulation-associated  object  instance  representation  shall  be  in  the 
federates,  not  in  the  runtime  infrastructure  (RTI).  The  main  purpose  in  the  development 
of  HLA  was  to  separate  simulation  specific  functionality  (updating  values)  from  general 
purpose  supporting  infrastructure  (interaction  of  object  instances  across  the  federation). 
Representation  of  simulated  object  instances  (e.g.  ownership  of  instance  attributes,  where 
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"ownership"  is  defined  as  having  the  responsibility  to  update  values)  shall  take  place  in 
the  simulations  (federates).  The  RTI  provides  functiondity  similar  to  a  DIS  operating 
system  by  supporting  interaction  of  object  instances.  However,  the  RTI  may  own 
instance  attributes  associated  with  the  supporting  services,  such  as  declaration 
management,  within  the  federation  management  object  model.  But,  these  data  are  just 
used  by  the  RTI,  not  changed. 

3.  During  a  federation  execution,  all  exchange  of  FOM  data  among  federates  shall  occur 
via  the  RTI.  The  RTI  is  setup  such  that  it  provides  services  by  which  data  exchanged 
among  federates  in  a  federation  (intercommunication)  is  accomplished.  The  HLA  shall 
specify  a  set  of  interfaces  to  these  RTI  services  in  order  to  support  exchange  of  instance 
attribute  values  and  interactions  in  accordance  with  the  FOM  for  that  federation.  Based 
on  the  FOM,  it  will  be  the  responsibility  of  the  federate  to  identify  to  the  RTI  what 
information  they  will  provide  and  require  (which  data,  reliability  of  transport,  event 
ordering,  etc.),  along  with  instance  attribute  and  interaction  data  corresponding  to  the 
changing  state  of  object  instances  in  the  federate.  It  will  be  the  responsibility  of  the  RTI 
services  to  provide  Ae  coordination,  synchronization,  and  data  exchange  among  the 
federates  to  permit  a  coherent  execution  of  the  federation. 

4.  During  a  federation  execution,  federates  shall  interact  with  the  RTI  in  accordance  with 
the  HLA  interface  specification.  The  interface  specification  defines  how  simulations 
interact  with  the  infi-astructure.  Federates  will  use  these  standard  interfaces  to  interact 
with  the  RTI  for  accessing  RTI  services.  The  interface  specification  has  no  ownership  or 
say  so  about  specific  federate  data  to  be  exchanged  over  the  interface.  Data  exchange 
requirements  between  federates  shall  be  defined  in  the  FOM.  The  separation  of  the 
interfaces  firom  the  requirements  for  federate  data  exchange  allows  for  the  reuse  of  a 
common  interface  specification  across  the  broad  spectrum  of  simulation  applications, 
with  specific  application  needs  tailored  through  the  FOM  mechanism. 

5.  During  a  federation  execution,  an  instance  attribute  shall  be  owned  by  at  most  one 
federate  at  any  time.  In  HLA  different  federates  are  allowed  to  own  different  attributes 
of  the  same  object  instance.  For  example,  a  simulation  of  an  aircraft  might  own  the 
location  of  the  airborne  sensor  while  a  sensor  system  model  might  own  other  instance 
attributes  of  the  sensor.  By  allowing  at  most  one  federate  ownership  of  an  object  instance 
attribute  at  any  time  will  ensure  data  coherency  across  the  federation.  HLA  will  provide 
a  mechanism  to  transfer  ownership,  dynamically  during  execution,  from  one  federate  to 
another.  By  defining  ownership  at  the  instance  attribute  level  and  providing  the  tools  to 
hand  off  ownership  during  execution,  the  HLA  provides  a  flexible  toolset  for  using 
various  combinations  of  simulations  to  meet  user  needs. 


4.2.2  Federate  Rules 

A  federate  is  a  member  of  a  HLA  federation.  A  federate  may  include  federate  managers, 
data  collectors,  live  entity  surrogate  simulations,  model  simulations  or  passive  viewers. 
Below  are  the  five  rules  and  rational  that  apply  to  HLA  federates. 
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1.  Federates  shall  have  an  HLA  Simulation  Object  Model  (SOM),  documented  in 
accordance  with  the  HLA  OMT.  Federates  are  defined  as  simulations  or  other 
applications  such  as  simulation  managers,  data  collectors,  live  entity  interfaces,  and 
passive  viewers  participating  in  a  federation.  The  HLA  requires  each  federate  to  have  a 
simulation  object  model  (SOM)  which  will  include  those  object  classes,  class  attributes, 
and  interaction  classes  of  the  federate  that  can  be  made  public  in  a  federation. 

It  will  not  be  the  responsibility  of  HLA  to  prescribe  which  data  are  included  in  the  SOM, 
this  will  be  done  by  the  simulation  developer.  HLA  will  require  that  SOMs  be 
documented  in  a  prescribed  format  called  the  HLA  OMT. 

2.  Federates  shall  be  able  to  update  and/or  reflect  any  attributes  and  send  and/or  receive 
interactions,  as  specified  in  their  SOMs.  The  HLA  allows  federates  to  make  object 
representations  and  interactions  developed  for  internal  use  available  as  part  of  federation 
executions  for  external  use  with  objects  represented  in  other  federates.  These  capabilities 
for  external  interaction  shall  be  documented  in  the  SOM  for  the  federate.  These  federate 
capabilities  shall  include  the  obligation  to  export  updated  values  of  instance  attributes 
that  are  calculated  internally  in  the  federate  and  the  obligation  to  be  able  to  exercise 
interactions  represented  externally  (i.e.,  by  other  federates  in  a  federation).  By  designing 
federates  fi'om  the  outset  with  the  ability  to  present  internal  objects/attributes/interactions 
as  public,  the  mechanisms  for  reuse  of  the  simulation  will  be  in  place  from  the  start. 

3.  Federates  shall  be  able  to  transfer  and/or  accept  ownership  of  attributes  dynamically 
during  a  federation  execution,  as  specified  in  their  SOMs.  HLA  allows  for  different 
federates  to  own  different  attributes  of  the  same  object  instance  (e.g.,  a  simulation  of  an 
aircraft  might  own  the  location  of  the  airborne  sensor  while  a  sensor  system  model  might 
own  other  instance  attributes  of  the  sensor).  With  this  capability,  it  shall  be  possible  to 
allow  a  simulation  designed  for  one  purpose  to  be  coupled  with  one  designed  for  another 
purpose  to  meet  a  new  requirement.  By  building  in  the  capability  to  transfer  and  accept 
ownership  of  instance  attributes,  simulations  designed  in  accordance  with  the  HLA 
provide  the  basic  structural  tools  to  become  federates  in  the  widest  possible  range  of 
future  federations.  The  instance  attributes  of  a  federate  that  can  be  either  owned  of 
reflected,  and  that  can  be  dynamically  transferred  during  execution,  are  documented  in 
the  SOM  for  that  federate. 

4.  Federates  shall  be  able  to  vary  the  conditions  (e.g.,  thresholds)  under  which  they 
provide  updates  of  attributes,  as  specified  in  their  SOMs.  HLA  permits  federates  to  own 
(i.e.,  produce  updated  values  for)  attributes  of  object  instances  represented  in  the 
simulation  and  then  make  those  values  available  to  other  federates  through  the  RTI. 
Different  federations  may  specify  different  conditions  under  which  instance  attributes 
will  be  updated  (at  some  specified  rate,  when  the  amount  of  change  in  value  exceeds  a 
specified  threshold  such  as  altitude  changes  of  more  than  1000  feet,  etc.).  Widely  usable 
simulations  will  be  able  to  adjust  the  conditions  under  which  they  export  their  public 
instance  attributes  to  support  the  requirements  of  different  federations.  The  conditions 
applicable  to  the  update  of  specific  instance  attributes  of  a  federate  shall  be  documented 
in  the  SOM  for  that  federate. 
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5.  Federates  shall  be  able  to  manage  local  time  in  a  way  that  will  allow  them  to 
coordinate  data  exchange  with  other  members  of  a  federation.  The  HLA  time- 
management  structure  is  intended  to  support  interoperability  among  federates  using 
different  internal  time-management  mechanisms.  The  HLA  shall  support  these 
capabilities  provided  that  federates  adhere  to  certain  requirements  necessary  to  realize 
each  service.  To  achieve  these  goals  the  approach  to  time  management  is  being 
developed  to  provide  time-management  interoperability  among  disparate  federates. 
Different  categories  of  simulations  are  special  cases  in  this  unified  structure,  and 
typically  use  only  a  subset  of  the  RTFs  full  capability.  Federates  need  not  explicitly 
indicate  to  the  RTI  the  time-flow  mechanism  (time  stepped,  event  driven,  independent 
time  advance)  being  used  within  the  federate,  but  shall  utilize  the  RTI  services  (including 
time  management)  that  are  appropriate  for  coordination  of  data  exchange  with  other 
federates. 


4.3  RUNTIME  INFRASTRUCTURE 

The  RTI  is  the  general  purpose  distributed  operating  system  software,  which  provides  the 
common  interface  services  during  the  runtime  of  an  HLA  federation.  Its  primary 
function  is  that  of  a  data  distribution  mechanism.  Federates  send  information  through  the 
RTI,  which  distributes  the  information  to  the  appropriate  parties.  Each  RTI  component 
(linked  into  each  federate)  must  perform  synchronization  operations  with  the  other  RTI 
components  to  allow  a  federation  to  progress  in  time,  handle  ownership  management, 
join  federations,  and  update  Management  Object  Model  (MOM)  state.  The  RTI  does  not 
maintain  information  about  the  state  of  the  federation.  Nor  does  it  handle  any  semantics 
associated  with  the  interaction  between  the  federates,  such  as  what  coordinate  system  to 
use,  what  happens  during  a  collision,  or  how  to  dead-reckon  remote  vehicles.  Also,  the 
RTI  does  not  specify  the  exact  byte  layout  of  data  sent  across  the  network. 

The  RTI  provides  a  common  set  of  services  to  the  federates.  They  can  be  divided  into  six 
functional  interfaces  as  shown  in  figure  4.  The  HLA  is  not  the  RTI;  the  HLA  says  there 
will  be  an  RTI  that  meets  HLA  requirements  but  it  doesn't  specify  a  particular  software 
implementation.  RTI  software,  and  other  HLA  related  items,  are  available  now  and  can 
be  ordered  firom  the  DMSO  homepage  (http://hla.dmso.mil)  under  topic  "HLA  Software 
Distribution  Center".  Currently  six  ports  for  RTI  are  available  and  each  port  includes: 

•  RTI  software 

•  Installation  guide 

•  User  documentation 

•  Test  federate 

•  Sample  application 

Currently,  RTI  version  1 .0  is  available  and  version  1.3  is  planned  for  release  by  the 
second  quarter  of  calendar  year  98.  RTI  version  2.0  commercial  procurement  is 
underway  and  scheduled  to  be  released  late  98  (TBD). 
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4.4  INTERFACE  SPECIFICATION 

The  rational  to  develop  an  Interface  Specification  for  HLA  weis  to  establish 
interoperability  and  utilize  the  reuse  among  simulations  within  a  federation,  and  across 
functional  M&S  commxmities.  The  Interface  Specification  (ref.  5)  defines  the  interface 

services  between  the  runtime  infi'astructure  and  the  federates  subject  to  the  HLA.  As  ■ 

previously  mentioned  in  section  4.3,  the  interface  between  federates  and  RTI  are  divided 
into  six  service  groups.  Each  service  group  specification  includes: 

•  Name  and  Descriptive  Text 

•  Supplied  Arguments 

•  Returned  Arguments 

•  Pre-conditions 

•  Post-conditions 

•  Exceptions 

•  Related  Services 

The  six  HLA  RTI  service  groups  each  have  services  performed  under  that  group  as 
described  below  (ref.  5). 

1 .  Federation  Management:  Handles  the  creation,  dynamic  control,  modification,  and 
destruction  of  a  federation  execution.  This  group  has  includes  20  services  listed  below: 

•  Create  Federation  Execution 

•  Destroy  Federation  Execution 

•  Join  Federation  Execution 

•  Resign  Federation  Execution 

•  Register  Federation  Execution 

•  Confirm  Synchronization  Point  Registration 

•  Aimounce  Synchronization  Point 

•  Synchronization  Point  Achieved 

•  Federation  Synchronized 

•  Request  Federation  Save 

•  Initiate  Federate  Save 

•  Federate  Save  Begim 

•  Federate  Save  Complete 

•  Federation  Saved 

•  Request  Federation  Restore 

•  Confirm  Federation  Restoration  Request 

•  Federation  Restore  Begim 

•  Initiate  Federate  Restore 

•  Federate  Restore  Complete 

•  Federation  Restored 
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2.  Declaration  Management:  Enables  federates  to  declare  to  the  RTI  their  desire  to 
generate  (publish)  and  receive  (subscribe/reflect)  object  state  and  interaction  information. 
Federates  can  subscribe  to  only  the  objects  they  want  (or  have  the  capability)  to  receive, 
e.g.  tanks  might  need  only  data  pertaining  to  ground  movement,  or  airplanes  might  need 
only  data  pertaining  to  flight  activities.  This  group  contains  12  services  listed  below: 

•  Publish  Object  Class 

•  Unpublish  Object  Class 

•  Publish  Interaction  Class 

•  Unpublish  Interation  Class 

•  Subscribe  Object  Class  Attributes 

•  Unsubscribe  Object  Class 

•  Subscribe  Interaction  Class 

•  Unsubscribe  Interaction  Class 

•  Start  Registration  for  Object  Class 

•  Stop  Registration  for  Object  Class 

•  Turn  Interactions  On 

•  Turn  Interaction  Off 

3.  Object  Management:  Support  life  cycle  activities  of  objects  and  interactions.  Enables 
the  creation,  modification,  and  deletion  of  objects,  their  attributes  and  the  interactions. 
These  services  comprise  most  of  the  network  traffic  during  runtime.  This  group  contains 
17  services  listed  below: 

•  Register  Object  Instance 

•  Discover  Object  Instance 

•  Update  Attribute  Values 

•  Reflect  Attribute  Values 

•  Send  Interaction 

•  Receive  Interaction 

•  Delete  Object  Instance 

•  Remove  Object  Instance 

•  Local  Delete  Object  Instance 

•  Change  Attribute  Transportation  Type 

•  Change  Interaction  Transportation  Type 

•  Attributes  in  Scope 

•  Attributes  Out  of  Scope 

•  Request  Attribute  Value  Update 

•  Provide  Attribute  Value  Update 

•  Turn  Updates  On  for  Object  Instance 

•  Tiun  Updates  Off  for  Object  Instance 

4.  Ownership  Management:  Allows  federates  to  transfer  ownership  of  object  attributes  to 
other  participants  in  the  simulation.  Federates  transfer  ownership  based  on  federation 
execution  design  plans.  The  RTI  makes  the  decision  for  transactions  so  that  ownership  is 
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held  by  at  most  one  federate  at  any  time.  Ownership  acquisition  attempts  can  be  both 
invasive  or  based  on  opportunity.  This  group  has  16  services  listed  below: 

•  Unconditional  Attribute  Ownership  Divestiture 

•  Negotiated  Attribute  Ownership  Divestiture 

•  Request  Attribute  Ownership  Assumption 

•  Attribute  Ownership  Divestiture  Notification 

•  Attribute  Ownership  Acquisition  Notification 

•  Attribute  Ownership  Acquisition 

•  Attribute  Ownership  Acquisition  if  Available 

•  Attribute  Ownership  Unavailable 

•  Request  Attribute  Ownership  Release 

•  Attribute  Ovmership  Release  Response 

•  Cancel  Negotiated  Attribute  Ownership  Divestiture 

•  Cancel  Attribute  Ownership  Acquisition 

•  Confirm  Attribute  Ownership  Acquisition  Cancellation 

•  Query  Attribute  Ownership 

•  Inform  Attribute  Ownership 

•  Is  Attribute  Owned  by  Federate 

5.  Time  Management:  Provides  useful  services  for  setting,  synchronizing,  and  modifying 
simulation  clocks.  Time  Management  services  are  tightly  coupled  with  the  Object 
Management  services  so  that  state  updates  and  interactions  are  distributed  in  a  timely  and 
ordered  fashion.  This  group  has  23  services  listed  below: 

•  Enable  Time  Regulation 

•  Time  Regulation  Enabled 

•  Disable  Time  Regulation 

•  Enable  Time  Constrained 

•  Time  Constrained  Enabled 

•  Disable  Time  Constrained 

•  Time  Advance  Request 

•  Time  Advance  Request  Available 

•  Next  Event  Request 

•  Next  Event  Request  Available 

•  Flush  Queue  Request 

•  Time  Advance  Grant 

•  Enable  Asynchronous  Delivery 

•  Disable  Asynchronous  Delivery 

•  Query  Lower  Bound  Time  Stamp  (LBTS) 

•  Query  Minimum  Next  Event  Time 

•  Modify  Lookahead 

•  Query  Lookahead 

•  Retract 
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•  Request  Retraction 

•  Change  Attribute  Order  T5q)e 

•  Change  Interaction  Order  Type 

6.  Data  Distribution  Management:  Federates  can  provide  conditions  governing  when  to 
start  or  stop  transmitting  and  receiving  certain  pieces  of  data.  The  RTI  routes  data  from 
producers  to  consumers  based  on  Data  Distribution  Management  declarations.  During 
the  Federation  design,  routing  spaces  are  created  for  use  during  runtime.  These  are 
specified  at  federation  creation  time  in  the  Federation  Execution  Details  (FED)  file. 
There  are  13  service  associated  with  this  group: 

•  Create  Region 

•  Modify  Region 

•  Delete  Region 

•  Register  Object  Instance  with  Region 

•  Associate  Region  for  Updates 

•  Unassociate  Region  for  Updates 

•  Subscribe  Object  Class  Attributes  with  Region 

•  Unsubscribe  Object  Class  with  Region 

•  Subscribe  Interaction  Class  with  Region 

•  Unsubscribe  Interaction  Class  with  Region 

•  Send  Interaction  with  Region 

•  Request  Attribute  Value  Update  with  Region 

•  Change  Thresholds 

In  addition  to  the  six  service  groups,  the  Interface  Specification  also  includes  29  support 
services,  Management  Object  Model,  Federation  Execution  Data,  Application 
Programmers  Interfaces  (APIs),  and  Harel  state  charts  (ref  6). 


4.5  OBJECT  MODEL  TEMPLATE 

The  OMT  provides  a  standard  format  for  describing  a  simulation  in  terms  of  its  objects 
and  the  relationship  between  objects.  Objects  are  the  physical  things,  real-world  entities 
that  are  simulated,  and  the  relationship  is  the  event(s)  that  occur  in  simulations,  between 
objects. 

There  are  three  basic  characteristics  used  by  HLA  to  view  an  Object  -  identity,  state,  and 
behavior.  Features  that  distinguish  objects  from  one  another,  such  as  a  name,  are 
described  as  an  identity.  The  static  and  dynamic  properties  associated  with  an  object  at 
any  time  are  regarded  as  the  state.  Behavior  is.  described  as  how  an  object  acts  and  reacts 
with  respect  to  changes  in  state  (ref.  6). 

The  relationship  between  objects  is  specified  through  -  attributes,  association,  and 
interaction.  Parameters,  such  as  state  variables  of  an  object  that  can  he  accessible  to 
other  objects  are  called  attributes.  One  object  can  be  part  of  another  object  by  conceptual 
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connection  called  association.  Interaction  is  defined  as  the  influence  of  one  object's  state 
on  the  state  of  another  object,  such  as  detonations  and  collisions  (ref.  6). 

HLA  provides  a  template  to  characterize  object  models  (OMT).  The  rational  to  develop 
an  OMT  is  again  based  on  interoperability  and  reuse  of  simulations  and  a  common 
fi-amework.  Within  the  template  object  models  describe: 

•  Those  objects  chosen  to  represent  real-world  within  a  simulation  or  federation 

•  Attributes,  associations,  and  interactions 

•  Level  of  fidelity  by  which  these  objects  represent  the  real-world,  to  include 
spatial  and  temporal  resolution 

•  Models  and  algorithms  used  to  represent  the  objects 

The  OMT  also  consists  of  a  Federation  Object  Model  (FOM)  and  Simulation  Object 
Model  (SOM).  FOMs  are  used  to  describe  all  shared  information  essential  to  a  particular 
federation.  A  FOM  is  an  identification  of  the  essential  classes  of  objects,  object 
attributes,  and  object  interactions  that  are  supported  by  a  HLA  federation.  SOMs  are 
used  to  describe  objects,  attributes  and  interactions  within  a  simulation,  which  can  be 
used  externally  in  a  federation.  A  SOM  is  a  specification  of  the  intrinsic  capabilities  that 
an  individual  simulation  publicly  offers  to  federations.  The  standard  format  in  which 
SOMs  are  expressed  provides  a  means  for  federation  developers  to  determine  the 
suitability  of  simulation  systems  to  assume  specific  roles  within  a  federation. 


5.0  DIS-TO-HLA  CONVERSION 

Under  the  direction  fi-om  DoD  that  all  models  and  simulations  of  the  future  must  comply 
with  the  HLA,  the  question  is  what  to  do  with  the  legacy  models  currently  being  used. 
Particularly,  how  do  we  handle  the  transition  of  existing  Advanced  Distributed 
Simulations  to  the  HLA?  DMSO  is  supporting  several  experimental  applications  in  1996 
to  test  and  refine  the  HLA  concept.  Reference  3  describes  four  techniques  for  making  the 

Table  1.  Benefits  of  Four  Techniques  for  Transitioning  DIS  to  HLA  (ref  3) 


Wrapper 

Native 

PIU 

Forward 

Compatibility 

X 

X 

X 

Backward 

Compatibility 

X 

X 

Ease  of  use 

X 

X 

Low  Latency 

X 

X 

X 

Scalability 

X 

X 

X 

Takes  full 
advantage  of 
HLA 

X 

X 

19 


DIS  to  HLA  translation.  These  four  techniques  are  called  -  translator,  wrapper,  native, 
and  protocol  interface  unit  (PIU).  Some  are  simpler  and  more  cost-effective  than  others, 
and  each  has  advantages  and  disadvantages.  Table  1  lists  the  benefits  of  the  four 
techniques. 

From  the  table.  Forward  Compatibility  describes  the  technique's  ability  to  be  upgraded  to 
newer  versions  of  HLA.  Backward  Compatibility  describes  the  technique's  ability  to 
switch  between  HLA  and  DIS.  Ease  of  Use  means  the  simulation  requires  only  limited 
modifications  to  existing  software.  Low  Latency  means  the  technique  does  not  cause  a 
delay  between  sender  and  receiver.  The  Scalability  describes  the  technique's  ability  to 
interface  with  a  large  number  of  simulations.  As  discussed  in  reference  3,  these  four 
techniques  are  presented  in  detail  below: 

Translator:  This  technique  requires  a  separate  application  or  hardware  device  to  manage 
commimications  between  applications  that  use  different  protocols.  Ofl;en  another 
computer  is  placed  on  the  network  to  translate  network  traffic  between  the  different 
protocols.  Tliis  technique  requires  no  software  modifications  to  the  simulator,  but  the 
disadvantage  is  the  simulator's  latency  increases  roughly  by  a  factor  of  ten.  This 
technique  does  allow  limited  forward  and  backward  compatibility,  but  limits  the 
scalability  and  flexibility  of  the  simulator.  Another  disadvantage  when  using  this 
technique,  the  simulator  cannot  take  advantage  of  future  HLA  features. 


Figure  6.  The  Translator  Technique  (ref.  3) 

Wrapper:  This  technique  links  additional  code  to  a  DIS  application  to  provide 
interoperability  with  HLA  applications.  Software  is  added  underneath  the  simulation's 
DIS  interface  to;  (a)  translate  the  data  from  the  old  DIS  protocol  to  the  new  HLA  protocol 
just  before  it  is  sent  and  (b)  to  translate  the  data  fi'om  HLA  to  DIS  just  after  it  is  received. 
This  technique  does  not  require  additional  hardware  and  all  changes  are  made  via  limited 
modification  to  the  simulator’s  software.  Forward  and  backward  compatibility  requires 
software  changes,  and  like  the  translator  technique,  the  wrapper  does  not  allow  the 
simulator  to  take  advantage  of  HLA  specific  features. 
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Simulator 


HLA  Interface 


Figure  7.  The  Wrapper  Technique  (ref.  3) 

Native:  This  technique  requires  the  simulation  software  to  contain  all  necessary 
interfaces  to  the  network.  A  native  HLA  simulator  can  take  full  advantage  of  all  HLA 
features.  However,  these  advantages  come  at  the  expense  of  huge  software  modifications 
at  the  initial  transition  and  then  additional  modifications  for  any  future  protocol  changes. 
Also,  there  is  no  backward  compatibility. 


Figure  8.  The  Native  Technique  (ref  3) 

Protocol  Interface  Unit:  This  technique  supports  all  features  of  both  protocols,  and 
allows  switching  among  different  FOMs  within  HLA.  A  Protocol  Interface  Unit  (PIU)  is 
a  software  system  used  to  interface  the  simulation  with  the  network.  This  approach  may 
be  the  best  technique  to  update  a  DIS  simulator  to  HLA.  It  provides  an  easy  upgrade  path 
to  HLA,  while  maintaining  backward  compatibility  with  DIS.  A  PIU  requires  only 
minimal  modifications  to  the  simulation  software  and  provides  the  most  flexibility  when 
designing  a  new  simulation.  The  disadvantage  of  using  a  PIU  is  that  they  can  be  complex 
and  expensive  to  write  and  maintain.  MAK  Technologies  has  developed  a  PIU  called 
VR-Link^“,  which  has  one  application  programmer's  interface  (API  -  a  library  of  function 
calls  which  allows  a  federate  to  interact  with  the  RTI)  which  supports  all  the  features  in 
both  protocols,  DIS  and  HLA. 
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Figure  9.  The  Protocol  Interface  Unit  Technique  (ref.  3) 


6.0  CONCLUSION 

Under  the  direction  of  DoD,  future  M&S  efforts  will  be  required  to  comply  with 
architecture  called  HLA  to  ensure  interoperability  and  reuse.  DoD  policy  has  stated  that 
on  the  first  day  of  FY99  no  funds  will  be  available  for  developing/modifying  non-HLA- 
compliant  simulations.  On  the  first  day  of  FYOl  non-HLA-compliant  simulations  will  be 
retired.  The  new  direction  has  brought  about  significant  advances  in  M&S  in  four  areas: 

•  Architectures,  standards,  and  protocols 

•  Representation  of  the  environment,  systems,  and  human  behavior 

•  Fielding  of  M&S  and  associated  infrastructure 

•  Outreach  activities 

Given  a  shrinking  force  structure,  limited  resources,  more  demanding  operation 
requirements,  and  more  technical  capability,  the  ADS  concepts  will  offer  a  cost  effective 
and  affordable  solution  for  training,  performance  assessment,  test  and  evaluation,  and 
analysis.  As  DIS  moves  into  the  direction  of  HLA  existing  models  will  be  required  to 
make  the  transition.  This  document  has  provided  the  fundamentals  associated  with 
developing/transitioning  advanced  M&S  concepts  of  the  future  as  required  by  DoD. 
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